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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2002). All Rights Reserved. 
Abstract 


This document specifies guidelines that must be implemented by any 
entity responsible for allocating IPv6 multicast addresses. This 
includes, but is not limited to, any documents or entities wishing to 
assign permanent IPv6 multicast addresses, allocate dynamic IPv6 
multicast addresses, and define permanent IPv6 multicast group 
identifiers. The purpose of these guidelines is to reduce the 
probability of IPv6 multicast address collision, not only at the IPv6 
layer, but also at the link-layer of media that encode portions of 
the IP layer address into the MAC layer address. 


Haberman Standards Track [Page 1] 


RFC 3307 IPv6 Multicast Addresses Guidelines August 2002 


Table of Contents 


Tso Terminology serere oi bereits E e os Give: iron arlene ace oie ee ah Giver E E E E geo eer eee 2 
Bote TVG EOC UG IE KSA se aicte teh eee: tie e ene es ete ar aan hse as Seagate he ted E E eee ea igre aaa AGM Te 2 
Sae APP WTC A Tel ay ae a satis Sais ns a E Seo wt aee een E SE E at A E E 3 
4s Group ID- Selection Guidelines. are iei e e ig a SORA a E E OAND 3 
4.1 Permanent IPv6 Multicast Addresses........ eee ee eee eee ee ees 4 
4.2 Permanent IPv6 Multicast Group Identifiers.................... 4 
4.3 Dynamic IPv6 Multicast Addresses... .... ee eee ee ee ee ee ees 4 
43.1 Server AL TOCAEV ON sees ed nie Bee ole eee eve ania leg Shatin ee aaa Jee eb erates 5 
4362 HOS Allocation eceso Sieg u acd) pele ee eae Behe eee aed Se ee are Shae eens 288 5 
54 TANA COnSTOET ACTON Sic ede Oe eas a is: ae Roe Sha dea at tak Se 5 
6; Security Considerations sss sasea oc e eer eens al als cower. Qed ye wie Sd Bl ew eee 6 
T Acknowledgements. a: Siesta ss or eae aE Miele ces eRe ae ah ho Mah g eve aia ena wee Olen oie Mang eres 6 
84 RELETENCES so cai ahs hd Seed BAS OE ds ee Sh Be a OS E SE Saeed WR ee we ae 6 
Authors Addres Sie sees eee ae iota apie tena aia Bes ete See oleel'e! e e a E e Sates Gut E E spear esos 7 
Buk Cöpyrrght statements sss araa ee ANa lea oe N a ey E AE E A We aoe ele 8 


1. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC 2119]. 


The term "group ID", throughout this document, conforms to the 
definition contained in [UNIMCAST], that is, the low-order 32 bits of 
the IPv6 multicast address. 


2. Introduction 


This document specifies guidelines that MUST be implemented by any 
entity responsible for allocating IPv6 multicast addresses. This 
includes, but is not limited to, any documents or entities wishing to 
assign permanent IPv6 multicast addresses, allocate dynamic IPv6 
multicast addresses, and define permanent IPv6 multicast group 
identifiers. The purpose of these guidelines is to reduce the 
probability of IPv6 multicast address collision, not only at the IPv6 
layer, but also at the link-layer of media that encode portions of 
the IP layer address into the link-layer address. 


With the current IPv6 address architecture [ADDRARCH] and the 
extension to the multicast address architecture specified in 
[UNIMCAST], a set of guidelines is needed for entities assigning any 
flavor of IPv6 multicast addresses. 


The current approach of several physical media [RFC 2464] [RFC 2467] 


is to map a portion of the IPv6 multicast address into a link-layer 
destination address. This is accomplished by taking the low order 32 
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bits (henceforth called the group ID) of the IPv6 multicast address 
and including them in the link-layer destination address. Group IDs, 
less than or equal to, 32 bits long will generate unique link-layer 
addresses within a given multicast scope. 


These guidelines specify how the group ID of the IPv6é multicast 
address are chosen and assigned. The guidelines specify several 
mechanisms that can be used to determine the group ID of the 
multicast address, based on the type of allocation being done. 


3. Applicability 


These guidelines are designed to be used in any environment in which 
IPv6 multicast addresses are delegated, assigned, or selected. These 
guidelines are not limited to use by MADCAP [RFC 2730] servers. The 
following is a non-exhaustive list of applications of these 
guidelines: 


-— Source-specific multicast application servers can generate an 
SSM group address by generating a 96-bit multicast prefix, as 
defined in [UNIMCAST] (i.e. FF3x::/96) and concatenating that 
with a group ID, as defined in this document. 


- A MADCAP server allocates IPv6 multicast addresses conforming 
to section 2.7 of [ADDRARCH], creating the group ID using the 
rules defined in this document. 


- Nodes supplying multicast services in a zeroconf environment 
generate multicast addresses without the need of centralized 
control. 


- IANA can assign permanent multicast addresses to fulfill 
requests via the protocol standardization process. 


4. Group ID Selection Guidelines 


The Group ID selection process allows for three types of multicast 
address assignments. These are permanent IPv6 multicast addresses, 
dynamic IPv6 multicast addresses, and permanent IPv6 multicast group 
IDs. The following guidelines assume that the prefix of the 
multicast address has been initialized according to [ADDRARCH] or 
[UNIMCAST]. 
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4.1 Permanent IPv6 Multicast Addresses 


Permanent multicast addresses, like those defined in [RFC 2375], are 
allocated by IANA. These addresses will be assigned with group ID’s, 
in the range of 0x00000001 to Ox3FFFFFFF, on an Expert Review basis. 


Multicast addresses assigned by IANA MUST have the T bit set to 0 and 
the P bit set to 0. 


4.2 Permanent IPv6 Multicast Group Identifiers 


Permanent group IDs allow for a global identifier of a particular 
service (e.g. Network Time Protocol (NIP) being assigned the group ID 
0x40404040). The use of permanent group IDs differs from permanent 
multicast addresses in that a permanent group ID offers a global 
identifier for a service being offered by numerous servers. 


As an example, consider the NTP example group ID of 0x40404040. An 
NTP client would be able to access multiple servers and multiple 
scopes. That is, the NTP client will know that the group ID 
0x40404040 identifies an NTP multicast stream regardless of the upper 
96 bits of the multicast address. 


Permanent group IDs are allocated on an Expert Review basis, in the 
range 0x40000000 to Ox7FFFFFFF. These permanent group IDs are meant 
to be used in IPv6 multicast addresses, defined in [UNIMCAST]. 


4.3 Dynamic IPv6 Multicast Addresses 


Dynamic IPv6 multicast addresses can be allocated by an allocation 
server or by an end-host. Regardless of the allocation mechanism, 
all dynamically allocated IPv6 multicast addresses MUST have the T 
bit set to 1. This will distinguish the dynamically allocated 
addresses from the permanently assigned multicast addresses, defined 
in [RFC 2375], at the link-layer on any media that maps the lower 
portion of the IPv6 multicast address into a link-layer address. It 
should be noted that the high-order bit of the Group ID will be the 
same value as the T flag. 


As an example, the permanent IPv6 multicast address FF02::9 maps to 
an Ethernet group address of 33-33-00-00-00-09. A dynamically 
allocated IPv6 multicast address of FF32::8000:9 would map to the 
Ethernet group address 33-33-80-00-00-09. 
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4.3.1 Server Allocation 


The allocation of IPv6 multicast addresses, by a server, is defined 
in [RFC 2730]. Address management is the responsibility of the 
allocation protocol and outside the scope of this document. 
Allocation servers MUST use the group ID range 0x80000000 to 
OxFFFFFFFF. 


4.3.2 Host Allocation 


Host-based allocation allows hosts to self-select IPv6 multicast 
addresses. One example of host-based allocation is the Zeroconf 
Multicast Address Allocation Protocol [ZMAAPDOC]. Issues with 
collision detection, claim notification, etc. are outside the scope 
of this document and the responsibility of the protocol being used, 
such as [ZMAAPDOC]. 


The group ID portion of the address is created using either a 
pseudo-random 32-bit number or a 32-bit number created using the 
guidelines in [RFC 1750]. The generated group ID MUST fall in the 
range 0x80000000 to OxFFFFFFFF. This can be accomplished by setting 
the high-order bit of the generated number to 1. 


5. IANA Considerations 


This document requests the creation of a new registry maintained by 
IANA. This new registry will maintain permanent group ID values. The 
premise of this new registry is to allow for permanent group IDs to 
be used across multiple domains utilizing the multicast address 
architecture defined in [UNIMCAST]. The permanent group IDs will 
fall in the range 0x40000000 to Ox7FFFFFFF. 


In addition, this document also defines rules for the allocation of 
permanent IPv6é multicast addresses by IANA. These rules specify 
different ranges for multicast addresses that are IPv6-only and for 
IPv6 multicast addresses that have corresponding IPv4 multicast 
addresses. 


Following the policies outlined in [RFC 2434]: 
- Permanent IPv6é multicast addresses with corresponding IPv4 
multicast addresses, like those defined in [RFC 2375], are 


allocated with group ID’s in the range of 1 to Ox3FFFFFFF on an 
Expert Review basis, see Section 4.1. 
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- Permanent IPv6-only multicast addresses are allocated with 
group ID’s in the range 0x100 to Ox3FFFFFFF on an Expert Review 
basis. 

- Permanent group ID’s are allocated on an Expert Review basis in 
the range 0x40000000 to Ox7FFFFFFF, see Section 4.2. 

- The range 0x80000000 to OxFFFFFFFF is reserved for use by 
dynamic multicast address allocation mechanisms, see Section 
Faa 


All approved requests for a permanent IPv6 multicast address will 
result in the assignment of a unique group ID which shall be reserved 
in all valid IPv6 multicast scopes. 


6. Security Considerations 


The allocation mechanisms described in this document do not alter the 
security properties of either the Any Source or Source Specific 
multicast service models of IPv4 and IPv6. 


The potential to allocate large blocks of addresses can lead to 
Denial-of-Service attacks. A more in-depth discussion of the 
security issues surrounding dynamic allocation of multicast addresses 
can be found in [RFC 2908]. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2002). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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